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The Domain Names Plan and Schedule 


This RFC outlines a plan and schedule for the implementation of domain 
style names throughout the DDN/ARPA Internet community. The 
introduction of domain style names will impact all hosts on the DDN/ARPA 
Internet. 


The Plan 
Introduction 


Domain style names are being introduced in the Internet to allow a 
controlled delegation of the authority and responsibility for 
adding hosts to the system. This also allows a subdivision of the 
task of maintaining information about hosts. 


The subdivision will be based on administrative authority or 
organization boundaries (not necessarily network boundaries). 
Certain requirements will be placed on organizations wishing to be 
"top level" domains. Initially, all the hosts in the Internet 
will be in the domain "ARPA". As soon as is practical a second 
domain, "DDN", will be introduced. Other domains may be added 
after that, provided the requirements listed below are met. 


Domain names will be supported in the long run by a system of 
special servers called "domain servers" which will be used to 
translate names to addresses. While this system of domain servers 
is being created and programs are being converted to use them, the 
existing host tables will evolve to include domain style names. 


The domain server design also provides for mapping mailbox 
addresses to the host name of the mail server for that mailbox. 
This feature allows mailboxes to be related to an organization 
rather than to a specific host. 


This plan will be implemented in the ARPA community. After the 
domain system is demonstrated in the ARPA community, the DDN 
Program Management Office (DDN-PMO) will determine the schedule 
for implementation of the domain system in the DDN community. 
This approach will cause some extra steps in the ARPA community 
implementation, and may limit communication between the ARPA and 
DDN communities in some ways. The details and implications of 
this two phase approach are discussed more fully below. 
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A Catch 22 


There is a problem in introducing domain style names: a great deal 
of software has to be changed. Some groups would like to start 
using domain style names right away, and other groups don’t want 
to see them or use them for a very long time. Communication 
patterns are very complex and as soon as domain style names are 
allowed and used by a few groups they will start showing up almost 
everywhere. This argues that everyone should be prepared for them 
before they are used at all. However, we know that with people 
being people and with so many of people involved, the probability 
of everyone being ready in any reasonable time period is nearly 
zero. The way out of this situation is to set up a reasonable 
schedule for experimenting with domain style names and authorizing 
their use. People that get ready on schedule should have no 
problems with these names. 


Evolution of the Table 


Nearly all the hosts in the Internet now use some form of host 
table based on the master file "HOSTS.TXT" maintained by the 
Network Information Center (NIC). 


One way to introduce domain style names is to add to the entries 


in this table names in the domain style. In particular, make the 
first name in each entry the official host name in the ARPA 
domain. 


For example, the current entry for USC-ISIF is: 


HOST : 10.2.0.52 : USC-ISIF,ISIF : DEC-1090T : TOPS20 
TCP/TELNET, TCP/SMTP, TCP/FTP, TCP/FINGER, UDP/TFTP 


This could become: 


HOST : 10.2.0.52 : USC-ISIF.ARPA,USC-ISIF,ISIF : DEC-1090T 
TOPS20 : TCP/TELNET, TCP/SMTP, TCP/FTP, TCP/FINGER, UDP/TFTP 


For some hosts and programs this could be done today with no 
disruptions, but for others substantial problems could occur. For 
example, with over five hundred entries in the table the addition 
of 500 names could exceed the space allocated to store the table 


in some programs. (One could argue that these programs are going 
to blow up soon anyway as new host entries are added to the 
table.) Another problem is that period (or dot, ".") is not now a 


legal character in host names and some programs may not be able to 
parse these new names. 
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The plan is to make such a domain style name table available in 
parallel with the regular table for a few months, then to replace 
the regular table with this domain style table. The dates for 
these changes is given in the schedule below. 


So far, no new domains have been introduced. Only a table with 
all the entries having official names in the ARPA domain has been 
provided. This should allow programs to be constructed to deal 
with domain style names in a general way without any special hacks 
to add or delete the string ".ARPA" to or from host names. 


The introduction of new domains is tied to the provision of domain 
servers by those domains. As new domains meet the requirements 
and are authorized they will also be added to the host table. No 
new domains will be added before master table is converted to the 
domain style entries. 


In the long run the Internet will become too complex and change 
too fast to keep a master table of all the hosts. At some point 
the master table will be reduced to simply the entries for the 
domain servers for the top level domains. By this time all normal 
translation of host names into addresses should take place by 
consulting domain servers. 


Conversion to Servers 


As soon as domain servers become available programs should be 
converted to use them to translate names into addresses. The 
details of these procedures are given in RFCs 882 and 883. 


The general idea is that a host no longer keeps a complete host 
table but rather makes a request on the domain server each time a 
name must be translated to an address. The code module in the 
host that implements the protocol to do this is called a 
"resolver". The resolver may keep a cache of recently translated 
names and addresses for improved performance. 


Many hosts have a library function or system call that is used to 
access the host table to translate names to addresses. It ought 
to be possible to replace this function or call with the resolver 
module such that most programs would not know which method was 
used to accomplish the name to address translation. 
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There are several requirements that must be met to establish a 
domain. In general it must be responsibly managed. There must be 
a responsible person to serve as a coordinator for domain related 
questions, there must be a robust name service, it must be of at 
least a minimum size, and the domain must be registered with the 
central domain administrator. 


Responsible Person: 


An individual must be identified who has authority for the 
administration of the names within the domain, and who takes 
responsibility for the behavior of the hosts in the domain in 
their interactions with hosts outside the domain. 


The operation of a name server should not be taken on lightly. 
There are some difficult problems in providing an adequate 
service, primarily the problems in keeping the data base up to 
date, and keeping the service operating. 


If some host in a domain somehow misbehaves in interactions 
with hosts outside the domain (e.g., consistently violates 
protocols), the responsible person for the domain must be able 
to take action to eliminate the problem. 


Domain Servers: 


A robust and reliable domain service must be provided. One way 
of meeting this requirement is to provide at least two 
independent domain servers for the domain. The data base can, 
of course, be the same. The database can be prepared and 
copied to each domain server. But, the servers should be in 
separate machines on independent power supplies, et cetera; 
basically as physically independent as can be and yet in the 
same domain. They should have no common point of failure. 


One of the difficult problems in operating a domain server is 
the acquisition and maintenance of the data. In this case the 
data is the host names and addresses. In some environments 
this information changes fairly rapidly and keeping up-to-date 
data may be difficult. This is one motivation for sub-domains. 
One may wish to create sub-domains until the rate of change of 
the data in a sub-domain domain server data base is easily 
managed. 


The concepts and implementation details of the domain server 
are given in RFCs 882 and 883. 
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Minimum Size: 


The domain must be of at least a minimum size. Several 
measures of size may be used in combination in making this 
test. Measures may include: (a) the number of host computers 


in the domain, (b) the number of people with primary mailboxes 
in the domain, (c) the amount of traffic that crosses the 
boundary of the domain [packets/day or mail items/week]. 
Specific threshold values for these measures will be 
established before new domains are authorized. 


There is no requirement to form a domain because some set of 
hosts is above the minimum size. 


Registration: 


The administrator must register the domain with the central 
authority. The central authority must be satisfied that the 
requirements are met before authorization for the domain is 
granted. 


The administrator of a domain is required to make sure that 
host and sub-domain names within that jurisdiction conform to 
the standard name conventions and are unique with in that 
domain. 


If sub-domains are set up the administrator may wish to pass 
along some of his authority and responsibility to a sub-domain 
administrator. 


Mailbox Support 


The design of the domain servers provides two levels of support 
for mail. 


The first, called "agent binding", is that the right hand part of 
the typical mail box (Y in X@Y) can be mapped a host that will 
either accept the mail as the destination or accept the mail for 
forwarding. 


The second, called "mailbox binding", is to map the entire mailbox 
(X@Y) to a destination (this mechanism can also support some 


mailing list functions). 


Agent binding can be used to establish mailboxes that are based on 
an organization name rather than a host name. 


For example, an organization, "BLAT", with hosts "BLAT-20" and 
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"BLAT-VAX" in the ARPA domain could set up mailboxes of the 
form "user@BLAT.ARPA" and use the domain server mechanisms for 
mapping these to the host that accepts the mail for the 
organization. 


Mailbox binding will allow different mappings for individual 
mailboxes of an organization or host to the destination host. It 


will also provide for aliases and mailing groups. 


Mailbox binding requires adding information on individual 


mailboxes to the domain server database. This could be a 
substantial increase in the database size and management 
responsibility. 


The ARPA Community and the DDN Community 
This plan will be put into effect in the ARPA community. 


The DDN community will adopt the domain style names, but will 
continue with the present scheme of a centrally maintained table 
copied periodically by each host. Once the use of domain servers 
has been demonstrated by use in the ARPA community, the DDN-PMO 
will establish a schedule for implementing the domain system in 
the DDN community. 


This means that there may be a period of a year or more with the 
two communities using different schemes for distributing 
information about host names and addresses. 


Specifically: 


The NIC will maintain a table a "HOSTS.TXT" style table for use 
by DDN hosts. This table will contain domain style names for 
all DDN hosts (e.g., USC-ISIA.DDN). Since this is the only 
information DDN hosts will use to translate host names to 
Internet Addresses, this table must also contain names and 
addresses of ARPA community hosts of interest to DDN users 
(e.g., USC-ISIF.ARPA). 


There will be a domain server with data for the DDN domain. 
That is, hosts in the ARPA community that use the domain system 
of resolvers and servers will be able to access servers that 
have the data base covering the DDN community. 


It is quite likely that the table for the use of the DDN hosts 
will be incomplete with respect to coverage of the ARPA community 
and any new domains that are established. One motivation for the 
domain system is the subdivision of name management to avoid the 
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difficulty of keeping a global table of all hosts. As the ARPA 
community moves to significant use of the domains system the 
maintenance of a global table for use by the DDN community will 
become very difficult. 


This means that DDN hosts might not be able to look up the names 
of some ARPA community hosts in their local tables. In some cases 
this might result in an inability establish communication from a 
DDN hosts to such "unknown" ARPA community hosts. 


The most likely case is for a computer mail message sent from 
an ARPA community user on a host know to name servers but not 
in the central table to a user on a DDN community host that 
relies on a local copy of the central table. When the DDN user 
attempts to answer this message his mail program will attempt 
to look up the host name. This will fail, and the most likely 
result is that the mail program will tell the user that there 
is no such host! 


Please note that DDN community hosts are permitted (even 
encouraged) to implement the domain system in parallel with the 
ARPA community. However, there is no requirement that they do so 
until called for in the schedule to be established by the DDN-PMO. 
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04-Oct-83 The ARPANET/MILNET Logical Split 
02-Nov-83 Publish Domain Name Documents 
This Plan and Schedule (RFC-881), Domain Names - Concepts and 
Facilities (RFC-882), and Domain Names - Implementation 
Specification (RFC-883). 


16-Nov-83 Make Available Domain Style Host Table 


Create a copy a modified version of the HOSTS.TXT table named 


DHOSTS.TXT with an additional name (as the first name) in each 


entry of the form "official-host-name.ARPA". 


15-Dec-83 Final Specification of simple Query & Reply Protocol 
Available 


This specification covers the protocol procedures and message 


1983 


formats for the simple queries and replies to support translating 


host names to internet addresses only. 


15-Dec-83 Make Limited Domain Server & Resolvers Available 


An example limited domain server running on TOPS-20 and example 
limited resolvers running on each of TOPS-20 and VAX-Berkeley-Unix 


should be made available for testing and copying. This simple 


version would be able to do queries and responses for host name to 
internet address translation only, and the servers would still use 
the global table. This simple server would not refer the resolver 
to another server. This simple server and these resolvers operate 
in datagram mode only. However, this would allow user programs to 


begin to use the servers. 


01-Feb-84 Specification of Domain Requirements Available 


Detailed requirements for qualifying a set of hosts as a domain, 


and procedure for registering new domains is published. 


15-Feb-84 The ARPANET/MILNET Access Controls 


MILNET access controls installed in the MILNET/ARPANET gateways 
and TAC user access controls put into effect (see DDN MGT Bulletin 


16). [Date approximate. ] 
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07-Mar-84 Replace Main Host Table with Domain Style Host Table 
The DHOSTS.TXT becomes HOSTS.TXT. 
14-Mar-84 Final Specification of Query & Reply Protocol Available 


This specification covers the protocol procedures and message 
formats for the all queries and replies between resolvers and 
servers. 


14-Mar-84 Make Improved Domain Servers & Resolvers Available 


An example improved domain server running on TOPS-20 and example 
improved resolvers running on each of TOPS-20 and 
VAX-Berkeley-Unix should be made available for testing and 
copying. This version should be able to do any of the defined 
query and response operations, and should support segmented data 
base by refering resolvers to other servers if necessary. This 
server loads zone data from local master files only, and only at 
program start up. This server and these resolvers operate with 
either datagram or reliable connection style communication. This 
version does not support the data base update portion of the 
server protocol. 


04-Apr-84 Domain Servers for ARPA Domain Available 


Authoritative domain servers for the ARPA domain will be available 
for regular use. 


02-May-84 Introduce New Domains in the Main Host Table 
Add the DDN domain. Most MILNET hosts will change to the DDN 
domain. Authoritative domain servers for the DDN domain will be 
available for regular use. HOSTS.TXT is updated. 


02-May-84 Establish a New Top Level Domains Only Table 


Start a new table, DOMAINS.TXT, that lists only the top level 
domains and the entries for their domain servers. 


16-May-84 Final Specification of Maintenance Protocol Available 


This specification covers the protocol procedures and message 
formats for the data base update exchanges between servers. 


16-May-84 Make Improved Domain Servers & Resolvers Available 


An example improved domain server running on TOPS-20 and example 
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improved resolvers running on each of TOPS-20 and 
VAX-Berkeley-Unix should be made available for testing and 
copying. This version should be able to do any of the defined 
query and response operations, and should support segmented data 
base by refering resolvers to other servers if necessary. This 
server loads zone data from local master files and remote servers, 
and only at program start up. This server and these resolvers 
operate with either datagram or reliable connection style 
communication. 


06-Jun-84 Permit the Introduction of New Domains 


Organizations meeting the requirements for establishing new 
domains will be allowed to begin use of new domain names. New 
domains must be registered, meet the requirements (including 
running domain servers), and will be added to the HOSTS.TXT table. 


18-Jul-84 Final Specification of Complete Protocol Available 


This specification covers the protocol procedures and message 
formats for the complete domain names system. 


18-Jul-84 Make Full Domain Servers & Resolvers Available 


At this point an example domain server and an example resolver 
running on each of TOPS-20 and VAX-Berkeley-Unix should be made 
available for testing and copying. This version should be able to 
do any of the defined query and response operations, and should 
support segmented data base by refering resolvers to other servers 
if necessary. This version should support the data base update 
portion of the server protocol, including data aging and dynamic 
zone updating from remote servers. This is a full implementation 
of the protocol. 


05-Sep-84 Discontinue the Full Host Table for the ARPA Community 
Stop maintaining the HOSTS.TXT table for the ARPA community. The 
HOSTS.TXT table continues to be used in the DDN community with 
complete data for the DDN domain, however the data for the ARPA 
and other domains may no longer be complete or fully up to date. 


03-Oct-84 DDN-PMO Schedules DDN Implementation 


The DDN-PMO establishes the schedule for the implementation of the 
domain system in the DDN community. 
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